เชี่ยวชาญ JavaScript module tree shaking เพื่อการกำจัด dead code อย่างมีประสิทธิภาพ เรียนรู้วิธีที่ bundler ช่วยเพิ่มประสิทธิภาพโค้ด ปรับปรุงความเร็ว และสร้างแอปพลิเคชันที่เล็กและเร็วขึ้นสำหรับผู้ใช้ทั่วโลก
JavaScript Module Tree Shaking: การวิเคราะห์เชิงลึกเรื่องการกำจัด Dead Code สำหรับนักพัฒนาระดับโลก
ในโลกดิจิทัลที่รวดเร็วในปัจจุบัน ประสิทธิภาพของเว็บเป็นสิ่งสำคัญที่สุด ผู้ใช้ทั่วโลกคาดหวังเวลาในการโหลดที่รวดเร็วปานสายฟ้าและประสบการณ์ผู้ใช้ที่ตอบสนองได้ดี ไม่ว่าพวกเขาจะอยู่ที่ไหนหรือใช้อุปกรณ์อะไร สำหรับนักพัฒนา frontend การบรรลุประสิทธิภาพระดับนี้มักเกี่ยวข้องกับการปรับปรุงโค้ดอย่างพิถีพิถัน หนึ่งในเทคนิคที่ทรงพลังที่สุดในการลดขนาด JavaScript bundle และเพิ่มความเร็วของแอปพลิเคชันเรียกว่า tree shaking บล็อกโพสต์นี้จะให้มุมมองที่ครอบคลุมในระดับสากลเกี่ยวกับ JavaScript module tree shaking โดยอธิบายว่ามันคืออะไร ทำงานอย่างไร ทำไมจึงสำคัญ และจะนำไปใช้อย่างมีประสิทธิภาพในกระบวนการพัฒนาของคุณได้อย่างไร
Tree Shaking คืออะไร?
โดยแก่นแท้แล้ว tree shaking คือกระบวนการกำจัดโค้ดที่ไม่ถูกใช้งาน (dead code elimination) ชื่อนี้ได้มาจากแนวคิดของการเขย่าต้นไม้เพื่อกำจัดใบไม้และกิ่งไม้ที่ตายแล้วออกไป ในบริบทของโมดูล JavaScript นั้น tree shaking เกี่ยวข้องกับการระบุและลบโค้ดที่ไม่ได้ใช้งานออกจาก build สุดท้ายของแอปพลิเคชันของคุณ เทคนิคนี้มีประสิทธิภาพโดยเฉพาะอย่างยิ่งเมื่อทำงานกับโมดูล JavaScript สมัยใหม่ ซึ่งใช้รูปแบบการเขียน import และ export (ES Modules)
เป้าหมายหลักของ tree shaking คือการสร้าง JavaScript bundle ที่มีขนาดเล็กลงและมีประสิทธิภาพมากขึ้น Bundle ที่เล็กลงหมายถึง:
- เวลาดาวน์โหลดที่เร็วขึ้นสำหรับผู้ใช้ โดยเฉพาะผู้ที่มีการเชื่อมต่ออินเทอร์เน็ตที่ช้าหรือในพื้นที่ที่มีแบนด์วิดท์จำกัด
- ลดเวลาในการประมวลผลและรันโค้ดของเบราว์เซอร์ ส่งผลให้หน้าเว็บโหลดเริ่มต้นได้เร็วขึ้นและประสบการณ์ผู้ใช้ที่ลื่นไหลมากขึ้น
- ลดการใช้หน่วยความจำฝั่ง client
รากฐานสำคัญ: ES Modules
Tree shaking อาศัยลักษณะที่เป็น static ของ синтаксис ES Module อย่างมาก ซึ่งแตกต่างจากระบบโมดูลรุ่นเก่าอย่าง CommonJS (ที่ใช้โดย Node.js) ซึ่งการ resolve dependencies ของโมดูลจะเกิดขึ้นแบบ dynamic ขณะ runtime แต่ ES Modules ช่วยให้ bundler สามารถวิเคราะห์โค้ดแบบ static ได้ในระหว่างกระบวนการ build
พิจารณาตัวอย่างง่ายๆ นี้:
`mathUtils.js`
export function add(a, b) {
return a + b;
}
export function subtract(a, b) {
return a - b;
}
export function multiply(a, b) {
return a * b;
}
`main.js`
import { add } from './mathUtils';
const result = add(5, 3);
console.log(result); // Output: 8
ในสถานการณ์นี้ ไฟล์ `main.js` นำเข้าเฉพาะฟังก์ชัน `add` จาก `mathUtils.js` เท่านั้น bundler ที่ทำการ tree shaking จะสามารถวิเคราะห์คำสั่ง import นี้แบบ static และสรุปได้ว่า `subtract` และ `multiply` ไม่เคยถูกใช้งานในแอปพลิเคชัน ด้วยเหตุนี้ ฟังก์ชันที่ไม่ได้ใช้งานเหล่านี้จึงสามารถถูกลบออกจาก bundle สุดท้ายได้อย่างปลอดภัย ทำให้มีขนาดเล็กลง
Tree Shaking ทำงานอย่างไร?
Tree shaking มักจะถูกดำเนินการโดย JavaScript module bundlers bundler ที่ได้รับความนิยมสูงสุดที่รองรับ tree shaking ได้แก่:
- Webpack: หนึ่งใน module bundler ที่ใช้กันอย่างแพร่หลายที่สุด พร้อมความสามารถในการทำ tree shaking ที่แข็งแกร่ง
- Rollup: ออกแบบมาโดยเฉพาะสำหรับการ bundling ไลบรารี Rollup มีประสิทธิภาพสูงในการทำ tree shaking และสร้างผลลัพธ์ที่สะอาดและเล็กที่สุด
- Parcel: bundler ที่ไม่ต้องตั้งค่า (zero-configuration) ซึ่งรองรับ tree shaking มาตั้งแต่ต้น
- esbuild: JavaScript bundler และ minifier ที่เร็วมาก ซึ่งมีการนำ tree shaking มาใช้ด้วย
กระบวนการโดยทั่วไปประกอบด้วยหลายขั้นตอน:
- Parsing: bundler จะอ่านไฟล์ JavaScript ทั้งหมดของคุณและสร้าง abstract syntax tree (AST) ซึ่งเป็นตัวแทนโครงสร้างของโค้ด
- Analysis: มันจะวิเคราะห์คำสั่ง import และ export เพื่อทำความเข้าใจความสัมพันธ์ระหว่างโมดูลและการ export แต่ละรายการ การวิเคราะห์แบบ static นี้คือกุญแจสำคัญ
- Marking Unused Code: bundler จะระบุ path ของโค้ดที่ไม่เคยถูกเข้าถึง หรือการ export ที่ไม่เคยถูกนำเข้า และทำเครื่องหมายว่าเป็น dead code
- Pruning: dead code ที่ถูกทำเครื่องหมายไว้จะถูกลบออกจากผลลัพธ์สุดท้าย ซึ่งมักจะเกิดขึ้นพร้อมกับการทำ minification โดยที่ dead code ไม่เพียงแต่ถูกลบออก แต่ยังไม่ถูกรวมอยู่ในไฟล์ bundle ด้วย
บทบาทของ `sideEffects`
แนวคิดที่สำคัญสำหรับการทำ tree shaking อย่างมีประสิทธิภาพ โดยเฉพาะในโปรเจกต์ขนาดใหญ่หรือเมื่อใช้ไลบรารีของบุคคลที่สาม คือแนวคิดของ side effects side effect คือการกระทำใดๆ ที่เกิดขึ้นเมื่อโมดูลถูกประมวลผล นอกเหนือจากการคืนค่าที่ export ออกไป ตัวอย่างเช่น:
- การแก้ไขตัวแปร global (เช่น `window.myApp = ...`)
- การส่งคำขอ HTTP
- การบันทึก log ไปยัง console
- การแก้ไข DOM โดยตรงโดยไม่ถูกเรียกใช้งานอย่างชัดเจน
- การ import โมดูลเพียงเพื่อ side effects ของมัน (เช่น `import './styles.css';`)
Bundler ต้องระมัดระวังในการลบโค้ดที่อาจมี side effects ที่จำเป็นออกไป แม้ว่าค่าที่ export ของมันจะไม่ได้ถูกใช้โดยตรงก็ตาม เพื่อช่วยให้ bundler ตัดสินใจได้ดียิ่งขึ้น นักพัฒนาสามารถใช้คุณสมบัติ "sideEffects" ในไฟล์ `package.json` ของตนได้
ตัวอย่าง `package.json` สำหรับไลบรารี:
{
"name": "my-utility-library",
"version": "1.0.0",
"sideEffects": false,
// ... other properties
}
การตั้งค่า "sideEffects": false จะบอก bundler ว่าไม่มีโมดูลใดในแพ็คเกจนี้ที่มี side effects ซึ่งจะช่วยให้ bundler สามารถตัดโค้ดโมดูลหรือ export ที่ไม่ได้ใช้ออกไปได้อย่างเต็มที่ หากมีเพียงบางไฟล์ที่มี side effects หรือหากต้องการให้บางไฟล์ถูกรวมไว้แม้ว่าจะไม่ได้ใช้งาน (เช่น polyfills) คุณสามารถระบุเป็นอาร์เรย์ของเส้นทางไฟล์ได้:
{
"name": "my-library",
"version": "1.0.0",
"sideEffects": [
"./src/polyfills.js",
"./src/styles.css"
],
// ... other properties
}
สิ่งนี้จะบอก bundler ว่าในขณะที่โค้ดส่วนใหญ่สามารถถูก shaken ได้ แต่ไฟล์ที่ระบุไว้ในอาร์เรย์ไม่ควรถูกลบออกไป แม้ว่าจะดูเหมือนไม่ได้ใช้งานก็ตาม นี่เป็นสิ่งสำคัญสำหรับไลบรารีที่อาจต้องลงทะเบียน global listener หรือดำเนินการอื่นๆ เมื่อถูก import
ทำไม Tree Shaking จึงสำคัญสำหรับผู้ใช้ทั่วโลก?
ประโยชน์ของ tree shaking จะเพิ่มขึ้นอย่างมากเมื่อพิจารณาถึงฐานผู้ใช้ทั่วโลก:
1. การลดความเหลื่อมล้ำทางดิจิทัล: การเข้าถึงและประสิทธิภาพ
ในหลายพื้นที่ของโลก การเข้าถึงอินเทอร์เน็ตอาจไม่เสถียร ช้า หรือมีราคาแพง JavaScript bundle ขนาดใหญ่อาจสร้างอุปสรรคสำคัญในการเข้าถึงสำหรับผู้ใช้ในภูมิภาคเหล่านี้ Tree shaking โดยการลดปริมาณโค้ดที่ต้องดาวน์โหลดและประมวลผล ทำให้เว็บแอปพลิเคชันเข้าถึงได้ง่ายและมีประสิทธิภาพมากขึ้นสำหรับทุกคน โดยไม่คำนึงถึงตำแหน่งทางภูมิศาสตร์หรือสภาพเครือข่ายของพวกเขา
ตัวอย่างระดับโลก: ลองนึกถึงผู้ใช้ในพื้นที่ชนบทของอินเดียหรือเกาะห่างไกลในมหาสมุทรแปซิฟิก พวกเขาอาจเข้าถึงแอปพลิเคชันของคุณผ่านการเชื่อมต่อ 2G หรือ 3G ที่ช้า bundle ที่ผ่านการ shaken มาอย่างดีอาจหมายถึงความแตกต่างระหว่างแอปพลิเคชันที่ใช้งานได้กับแอปพลิเคชันที่หมดเวลา (timeout) หรือช้าจนน่าหงุดหงิด การพัฒนาที่คำนึงถึงความครอบคลุมเช่นนี้เป็นเครื่องหมายของคุณภาพของการพัฒนาเว็บระดับโลกที่มีความรับผิดชอบ
2. ประสิทธิภาพด้านต้นทุนสำหรับผู้ใช้
ในภูมิภาคที่ข้อมูลมือถือมีราคาแพงและคิดตามปริมาณการใช้งาน ผู้ใช้จะอ่อนไหวต่อการใช้ข้อมูลเป็นอย่างมาก JavaScript bundle ที่เล็กลงแปลโดยตรงเป็นการใช้ข้อมูลที่น้อยลง ทำให้แอปพลิเคชันของคุณน่าสนใจและมีราคาที่เข้าถึงได้ง่ายขึ้นสำหรับกลุ่มประชากรที่กว้างขึ้นทั่วโลก
3. การใช้ทรัพยากรอย่างเหมาะสมที่สุด
ผู้ใช้จำนวนมากเข้าถึงเว็บด้วยอุปกรณ์รุ่นเก่าหรือมีประสิทธิภาพน้อย อุปกรณ์เหล่านี้มีกำลัง CPU และหน่วยความจำจำกัด การลดขนาด JavaScript payload ด้วย tree shaking จะช่วยลดภาระการประมวลผลบนอุปกรณ์เหล่านี้ ส่งผลให้การทำงานราบรื่นขึ้นและป้องกันแอปพลิเคชันขัดข้องหรือไม่ตอบสนอง
4. Time-to-Interactive ที่เร็วขึ้น
เวลาที่ใช้เพื่อให้หน้าเว็บสามารถโต้ตอบได้อย่างสมบูรณ์เป็นตัวชี้วัดที่สำคัญสำหรับความพึงพอใจของผู้ใช้ Tree shaking มีส่วนสำคัญในการลดตัวชี้วัดนี้โดยการทำให้แน่ใจว่ามีเพียงโค้ด JavaScript ที่จำเป็นเท่านั้นที่ถูกดาวน์โหลด ประมวลผล และรัน
แนวทางปฏิบัติที่ดีที่สุดสำหรับการทำ Tree Shaking อย่างมีประสิทธิภาพ
แม้ว่า bundler จะทำงานหนักเป็นส่วนใหญ่ แต่ก็มีแนวทางปฏิบัติที่ดีที่สุดหลายประการที่คุณสามารถปฏิบัติตามเพื่อเพิ่มประสิทธิภาพสูงสุดของ tree shaking ในโปรเจกต์ของคุณ:
1. ใช้ ES Modules
ข้อกำหนดพื้นฐานที่สุดสำหรับ tree shaking คือการใช้รูปแบบการเขียนของ ES Module (import และ export) หลีกเลี่ยงรูปแบบโมดูลรุ่นเก่าเช่น CommonJS (`require()`) ภายในโค้ดฝั่ง client ของคุณเท่าที่เป็นไปได้ เนื่องจาก bundler วิเคราะห์แบบ static ได้ยากกว่า
2. ใช้ไลบรารีที่ไม่มี Side-Effect
เมื่อเลือกไลบรารีของบุคคลที่สาม ให้เลือกไลบรารีที่ออกแบบมาโดยคำนึงถึง tree shaking ไลบรารีสมัยใหม่จำนวนมากมีโครงสร้างที่ export ฟังก์ชันหรือคอมโพเนนต์แยกกัน ทำให้เข้ากันได้ดีกับ tree shaking มองหาไลบรารีที่ระบุการรองรับ tree shaking ไว้อย่างชัดเจนและวิธีการ import อย่างมีประสิทธิภาพ
ตัวอย่าง: เมื่อใช้ไลบรารีอย่าง Lodash แทนที่จะเป็น:
import _ from 'lodash';
const sum = _.sum([1, 2, 3]);
ให้เลือกใช้ named imports:
import sum from 'lodash/sum';
const result = sum([1, 2, 3]);
วิธีนี้ช่วยให้ bundler รวมเฉพาะฟังก์ชัน `sum` เท่านั้น ไม่ใช่ทั้งไลบรารี Lodash
3. ตั้งค่า Bundler ของคุณให้ถูกต้อง
ตรวจสอบให้แน่ใจว่า bundler ของคุณได้รับการตั้งค่าให้ทำการ tree shaking สำหรับ Webpack โดยทั่วไปจะเกี่ยวข้องกับการตั้งค่า mode: 'production' เนื่องจาก tree shaking จะถูกเปิดใช้งานโดยค่าเริ่มต้นในโหมด production คุณอาจต้องตรวจสอบให้แน่ใจว่าแฟล็ก optimization.usedExports ถูกเปิดใช้งานด้วย
ตัวอย่างการตั้งค่า Webpack:
// webpack.config.js
module.exports = {
//...
mode: 'production',
optimization: {
usedExports: true,
minimize: true
}
};
สำหรับ Rollup, tree shaking จะถูกเปิดใช้งานโดยค่าเริ่มต้น คุณสามารถควบคุมพฤติกรรมของมันได้ด้วยตัวเลือกต่างๆ เช่น treeshake.moduleSideEffects
4. ระมัดระวัง Side Effects ในโค้ดของคุณเอง
หากคุณกำลังสร้างไลบรารีหรือแอปพลิเคชันขนาดใหญ่ที่มีหลายโมดูล ให้ตระหนักถึงการสร้าง side effects ที่ไม่ตั้งใจ หากโมดูลมี side effects ให้ทำเครื่องหมายอย่างชัดเจนโดยใช้คุณสมบัติ "sideEffects" ใน `package.json` หรือตั้งค่า bundler ของคุณให้เหมาะสม
5. หลีกเลี่ยง Dynamic Imports โดยไม่จำเป็น (เมื่อเป้าหมายหลักคือ Tree Shaking)
ในขณะที่ dynamic imports (`import()`) ยอดเยี่ยมสำหรับการทำ code-splitting และ lazy loading แต่บางครั้งก็อาจขัดขวางการวิเคราะห์แบบ static สำหรับ tree shaking ได้ หากโมดูลถูก import แบบ dynamic, bundler อาจไม่สามารถระบุได้ในขณะ build ว่าโมดูลนั้นถูกใช้งานจริงหรือไม่ หากเป้าหมายหลักของคุณคือการทำ tree shaking อย่างเต็มที่ ตรวจสอบให้แน่ใจว่าโมดูลที่ import แบบ static ไม่ได้ถูกย้ายไปเป็น dynamic import โดยไม่จำเป็น
6. ใช้ Minifier ที่รองรับ Tree Shaking
เครื่องมืออย่าง Terser (มักใช้กับ Webpack และ Rollup) ถูกออกแบบมาเพื่อทำงานร่วมกับ tree shaking พวกมันจะทำการกำจัด dead code เป็นส่วนหนึ่งของกระบวนการ minification ซึ่งช่วยลดขนาด bundle ลงไปอีก
ความท้าทายและข้อควรระวัง
แม้ว่าจะมีประสิทธิภาพ แต่ tree shaking ก็ไม่ใช่ยาวิเศษและมาพร้อมกับความท้าทายของตัวเอง:
1. Dynamic `import()`
ดังที่ได้กล่าวไปแล้ว โมดูลที่นำเข้าโดยใช้ dynamic `import()` จะทำการ tree shake ได้ยากกว่าเนื่องจากการใช้งานของมันไม่เป็นที่รู้จักแบบ static โดยปกติแล้ว bundler จะถือว่าโมดูลเหล่านี้อาจถูกใช้งานและรวมเข้าไปด้วย แม้ว่าจะถูก import ตามเงื่อนไขและเงื่อนไขนั้นไม่เคยเป็นจริงก็ตาม
2. การทำงานร่วมกับ CommonJS
Bundler มักจะต้องจัดการกับโมดูลที่เขียนด้วย CommonJS แม้ว่า bundler สมัยใหม่จำนวนมากสามารถแปลง CommonJS เป็น ES Modules ได้ในระดับหนึ่ง แต่มันก็ไม่ได้สมบูรณ์แบบเสมอไป หากไลบรารีอาศัยคุณสมบัติของ CommonJS ที่ถูก resolve แบบ dynamic มากเกินไป tree shaking อาจไม่สามารถตัดโค้ดของมันออกไปได้อย่างมีประสิทธิภาพ
3. การจัดการ Side Effects ที่ผิดพลาด
การทำเครื่องหมายโมดูลว่าไม่มี side effects อย่างไม่ถูกต้องในขณะที่มันมีอยู่จริง อาจทำให้แอปพลิเคชันพังได้ ซึ่งเป็นเรื่องปกติโดยเฉพาะอย่างยิ่งเมื่อไลบรารีแก้ไขอ็อบเจกต์ global หรือลงทะเบียน event listener เมื่อถูก import ควรทดสอบอย่างละเอียดเสมอหลังจากตั้งค่า `sideEffects`
4. กราฟ Dependency ที่ซับซ้อน
ในแอปพลิเคชันขนาดใหญ่ที่มีสายโซ่ dependency ที่ซับซ้อน การวิเคราะห์แบบ static ที่จำเป็นสำหรับ tree shaking อาจใช้ทรัพยากรในการคำนวณสูง อย่างไรก็ตาม ประโยชน์ที่ได้จากการลดขนาด bundle มักจะคุ้มค่ากับเวลาในการ build ที่เพิ่มขึ้น
5. การดีบัก (Debugging)
เมื่อโค้ดถูก shaken มันจะถูกลบออกจาก bundle สุดท้าย ซึ่งบางครั้งอาจทำให้การดีบักท้าทายมากขึ้น เนื่องจากคุณอาจไม่พบโค้ดที่คาดหวังในเครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์หากมันถูกกำจัดออกไป Source map เป็นสิ่งสำคัญในการลดปัญหานี้
ข้อพิจารณาสำหรับทีมพัฒนาระดับโลก
สำหรับทีมพัฒนาที่กระจายอยู่ตามเขตเวลาและวัฒนธรรมที่แตกต่างกัน การทำความเข้าใจและการนำ tree shaking มาใช้เป็นความรับผิดชอบร่วมกัน นี่คือวิธีที่ทีมระดับโลกสามารถทำงานร่วมกันได้อย่างมีประสิทธิภาพ:
- กำหนดมาตรฐานการ Build: กำหนดแนวทางที่ชัดเจนสำหรับการใช้โมดูลและการรวมไลบรารีภายในทีม ตรวจสอบให้แน่ใจว่าทุกคนเข้าใจถึงความสำคัญของ ES Modules และการจัดการ side-effect
- เอกสารเป็นกุญแจสำคัญ: จัดทำเอกสารเกี่ยวกับการตั้งค่า build ของโปรเจกต์ รวมถึงการตั้งค่า bundler และคำแนะนำเฉพาะใดๆ สำหรับการจัดการ side effects นี่เป็นสิ่งสำคัญอย่างยิ่งสำหรับสมาชิกใหม่ในทีมหรือผู้ที่มาจากภูมิหลังทางเทคนิคที่แตกต่างกัน
- ใช้ CI/CD: ผนวกรวมการตรวจสอบอัตโนมัติในไปป์ไลน์ Continuous Integration/Continuous Deployment ของคุณเพื่อติดตามขนาดของ bundle และระบุการถดถอยที่เกี่ยวข้องกับ tree shaking สามารถใช้เครื่องมือเพื่อวิเคราะห์องค์ประกอบของ bundle ได้อีกด้วย
- การฝึกอบรมข้ามวัฒนธรรม: จัดเวิร์กชอปหรือเซสชันแบ่งปันความรู้เพื่อให้แน่ใจว่าสมาชิกในทีมทุกคน ไม่ว่าจะมีที่ตั้งหลักหรือระดับประสบการณ์ใด มีความเชี่ยวชาญในการปรับปรุงประสิทธิภาพ JavaScript สำหรับประสิทธิภาพระดับโลก
- พิจารณาสภาพแวดล้อมการพัฒนาในระดับภูมิภาค: ในขณะที่การปรับปรุงประสิทธิภาพเป็นเรื่องระดับโลก การทำความเข้าใจว่าสภาพเครือข่ายที่แตกต่างกัน (จำลองในเครื่องมือสำหรับนักพัฒนา) ส่งผลต่อประสิทธิภาพอย่างไร สามารถให้ข้อมูลเชิงลึกที่มีค่าสำหรับสมาชิกในทีมที่ทำงานในสภาพแวดล้อมโครงสร้างพื้นฐานที่แตกต่างกัน
บทสรุป: เขย่าเส้นทางของคุณสู่เว็บที่ดีกว่า
JavaScript module tree shaking เป็นเทคนิคที่ขาดไม่ได้สำหรับนักพัฒนาเว็บสมัยใหม่ที่มุ่งสร้างแอปพลิเคชันที่มีประสิทธิภาพ รวดเร็ว และเข้าถึงได้ง่าย การกำจัด dead code ช่วยให้เราลดขนาด bundle ส่งผลให้เวลาในการโหลดเร็วขึ้น ประสบการณ์ผู้ใช้ที่ดีขึ้น และการใช้ข้อมูลที่ลดลง ซึ่งเป็นประโยชน์ที่ส่งผลกระทบอย่างยิ่งต่อผู้ชมทั่วโลกที่ต้องเผชิญกับสภาพเครือข่ายและความสามารถของอุปกรณ์ที่หลากหลาย
การยอมรับ ES Modules การใช้ไลบรารีอย่างชาญฉลาด และการตั้งค่า bundler ของคุณอย่างถูกต้องเป็นรากฐานสำคัญของการทำ tree shaking ที่มีประสิทธิภาพ แม้ว่าจะมีความท้าทายอยู่ แต่ข้อได้เปรียบด้านประสิทธิภาพและการเข้าถึงในระดับโลกนั้นไม่อาจปฏิเสธได้ ในขณะที่คุณสร้างสรรค์ผลงานสำหรับโลกต่อไป อย่าลืมเขย่าสิ่งที่ไม่จำเป็นออกไปและส่งมอบเฉพาะสิ่งที่จำเป็นเท่านั้น เพื่อทำให้เว็บเป็นสถานที่ที่เร็วขึ้นและเข้าถึงได้ง่ายขึ้นสำหรับทุกคน